-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update phased trigger and digitizer #799
base: develop
Are you sure you want to change the base?
Conversation
…phased_trigger_and_digitizer
@ryankrebs016 I merged the branch |
@@ -0,0 +1,349 @@ | |||
#!/bin/env python3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the purpose of this script? Compared to simulate.py
does it only add the two triggers and allows to use the NuRadioMCRunner? Can we not merge the two scripts into one (maybe we can have an second script which takes the simulation as defined in the first script but uses the runners?)
Vrms = fin.attrs['Vrms'] | ||
try: | ||
Vrms = fin.attrs['Vrms'] | ||
except: | ||
Vrms = 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, why is Vrms
not available? It should? Is 1
a good default value? I think you might be able to make this code a one-liner Vrms = fin.attrs.get('Vrms', 1)
if hdf5 attributes are compatible with python dictionaries.
"trigger_adc_noise_nbits": 3.321, | ||
"trigger_adc_noise_nbits": 2.585, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
has there been a change in the firmware? Is that available in the data?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No changes to firmware. See the next two comment threads for why this number changed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay but you removed the -1
there, why would you change this number here? Or do you only have to change the nbits if the -1
is in the voltage/adc conversion? Sorry something does not yet add up for me.
|
||
lsb_voltage = adc_ref_voltage / (2 ** (adc_n_bits - 1) - 1) | ||
|
||
lsb_voltage = adc_ref_voltage / (2 ** (adc_n_bits) - 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See discussion in #500, if we change this (which I in principle would be very happy with) we would need to update all existing json detector files and would break the code for all users with their own detector files in a very subtle and dangerous way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This just makes the code kind of confusing to follow. To me I would use lsb_voltage = voltage_range / (2^adc_n_bits -1). Instead, a ref_voltage is used and is calculated using the code in the comment below these.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I absolutely agree with you, I stumbled across this twice (more than a year apart from each other so I had forgotten). The issue is if we change it now we will effect all other users using this module. Maybe we should have this discussion in the issue I linked above?
adc_ref_voltage = Vrms * (2 ** (adc_n_bits - 1) - 1) / (2 ** (adc_noise_n_bits - 1) - 1) | ||
adc_ref_voltage = Vrms * (2 ** (adc_n_bits) - 1) / (2 ** (adc_noise_n_bits ) - 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment above
I like the idea of having a base class for the phased array trigger very much! But I think we should think about restructuring the code a bit. First, can you rename the phased array trigger modules to reflect the typically name scheme for modules in NuRadio? Should we put all modules in |
if np.any(mask): | ||
gain_to_use = self._triggerBoardAmplifications[mask][0] | ||
vrms_after_gain.append(amplified_vrms_values[mask][0]) | ||
volts_per_adc = self._adc_input_range / (2 ** total_bits) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is a -1
missing (not in the exponent). If you have a 8bit system you want to divide by 2 ** 8 -1 = 255
|
||
if digitize_trace: | ||
self.digitize_trace(station, det, trigger_channels, ideal_vrms) | ||
trigger_board_vrms = self.get_vrms(station, trigger_channels) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this line is a problem for two reasons. Lets start with the important one. You recalculate the vrms here which you use to define the trigger thresholds. However, if the traces are in ADC counts so should be the thresholds (I think). Hence if you self._adc_output == "counts"
you have to pass the trigger_board_vrms
through np.floor(trigger_board_vrms).dtype(int)
. The second reason, before if you passed vrms
as an argument to this module, what was returned was the amplified vrms. Now you always return the std(amplified_trace)
. I am not sure what we acutally want to do here but point out that you change what the module does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first reason isn't so much an issue as the traces are gain normalized and digitized so the output is in adc or voltage. Though I agree this can be removed. It was leftover when I was calculating trace rms awkwardly and was skeptical that the gain and digitization was affecting the rms and then thresholds. The assumption would be that if thresholds are stable (on an event by event basis) then the thresholds should be based on theoretical rms values. When calculating the thresholds in simulation, the code does the gain normalization and digitization so the resulting threshold is already informed that things get digitized etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
locally I already removed this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No - when you calculate the STD from a trace of ints you do not get and int back.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you removed this line, how do you convert the VRMS to have the "unit" ADC? I use the following code currently:
if vrms is None:
vrms = self.get_noise_vrms_per_trigger_channel(station, trigger_channels)
if apply_adc_gain:
equalized_vrms, ideal_vrms = self.apply_adc_gain(station, det, trigger_channels, vrms)
else:
equalized_vrms = vrms
ideal_vrms = vrms
if digitize_trace:
self.digitize_trace(station, det, trigger_channels, ideal_vrms)
if self._adc_output == "counts":
lsb_voltage = self._adc_input_range / (2 ** self._n_bits - 1)
equalized_vrms = np.floor(equalized_vrms / lsb_voltage).astype(int)
logger.debug("obs. Vrms {} ADC".format(equalized_vrms))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused, doesn't something like np.std(array_of_ints) return a float? Also vrms should not be forced to an int. The conversion should happen on the threshold if trying to match firmware
Do we want to include the change from adc_noise_nbits to something like adc_noise_counts to remove the ambiguous noise calculation? |
Changes: